home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1182 < prev    next >
Internet Message Format  |  1994-08-27  |  2KB
  1. Date: Fri, 29 Jul 94 23:24 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re: Gem List
  5. Precedence: bulk
  6.  
  7. ========================================================================
  8. In GEM++, I use a linked list, and go to the trouble of maintaining the
  9. list to be in the same order as the windows.  I'm still not sure how
  10. useful this is, since I could call wind_find(), then search an
  11. unordered list.  Comments?
  12. ========================================================================
  13.  
  14. Order of window handle, or order as in top window first, desktop last?
  15. I was planning on doing it that way because locking activity focus
  16. to the top window would be alot easier, and you would know what the
  17. second or third windows were instantly.  I think its useful.
  18.  
  19. ========================================================================
  20. I also never hold onto a window handle if the window is not open.
  21. This means keeping my own copies of the window sizes, but again,
  22. that hasn't been a problem.  Good for older TOSes.  Comments?  (Hey,
  23. maybe everyone does these things - I've not looked at the details of
  24. many libraries).
  25. ========================================================================
  26.  
  27. There are a couple, very few, instances when I would hold on to the
  28. window handle.   Currently, my plan is to call wind_create() in the
  29. alloc "factory" method (constructor), and wind_delete() would be
  30. called in the free method (as well as wind_close()).  And wind_open()
  31. would be called in the init method.  Since the "new" factory method
  32. calls alloc and init, you get a new open window, and you can split
  33. stuff up if needed.  I think I may also have a Hide and UnHide method.
  34. Hide would close the window (maybe iconify, or maybe create an icon
  35. and store it elsewhere) and UnHide would re-open the window.  Then you
  36. can send "Hide" to all your windows to clean up, or maybe send Hide to
  37. all but the top window. 
  38.  
  39. So, Yes, a closed window handle could exist doing it this way, but
  40. it probably won't.
  41.  
  42.